@swift-ci please test Linux

:(

19:18:12 [144/179] Compiling _StringProcessing CharacterClass.swift
19:18:12 error: compile command failed due to signal 6 (use -v to see invocation)Begin Error in Function: '$s17_StringProcessing7compile_7optionsAA6RECodeV15_MatchingEngine3ASTO_AA9REOptionsVtKF0C4NodeL_yyAHKF'
19:18:12 Error! Found a leak due to a consuming post-dominance failure!
19:18:12 Value:   %90 = load [take] %89 : $*{ var AST.Atom }      // users: %286, %242, %158, %143, %123, %91
19:18:12 Post Dominating Failure Blocks:
19:18:12  bb15
19:18:12 End Error in Function: '$s17_StringProcessing7compile_7optionsAA6RECodeV15_MatchingEngine3ASTO_AA9REOptionsVtKF0C4NodeL_yyAHKF'
19:18:12 Found ownership error?!
19:18:12 triggering standard assertion failure routine
19:18:12 

In the end, do we want to do this or would we want our sources to be slurped into the stdlib's Swift module? We'll need to figure out a direction regarding _Unicode, as we'll need to be able to call the same internal functionality as the stdlib.

IMO this should be part of the Swift module when it also becomes a package. Either way, the package will be built with resilience enabled in the compiler, and I think the package build config should be as close to that as possible.

This is failing with DEVELOPMENT-SNAPSHOT-2022-01-09-a (rdar://87427450). Note if I simply added -enable-library-evolution without fixing warnings by adding @unknown default:, the package compiles successfully. This is likely a SILGen bug, and I'm looking into it now.

I’d slightly prefer sticking frozen on the internal module’s enums,

I'll do that for the internal ones. CharacterClass however is the one that's triggering the SILGen bug, and it's public, so I still need to fix the bug.

Update: My bad. AST is triggering it. So marking AST as @frozen should fix it.

Ok, added a bunch of @frozen and there's no need for any @unknown default: now.

@swift-ci please test linux